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ABSTRACT 


Data referring to cultural calendars such as the widespread 
Gregorian dates but also dates after the Chinese, Hebrew, or 
Islamic calendars as well as data referring to professional cal- 
endars like fiscal years or teaching terms are omnipresent on 
the Web. Formalisms such as XML Schema have acknowl- 
edged this by offering a rather extensive set of Gregorian 
dates and times as basic data types. This article introduces 
into CaTTS, the Calendar and Time Type System. CaTTS 
goes far beyond predefined date and time types after the 
Gregorian calendar as supported by XML Schema. CaTTS 
first gives rise to declaratively specify more or less complex 
cultural or professional calendars including specificities such 
as leap seconds, leap years, and time zones. CaTTS fur- 
ther offers a tool for the static type checking (of data typed 
after calendar(s) defined in CaTTS). CaTTS finally offers 
a language for declaratively expressing and a solver for effi- 
ciently solving temporal constraints (referring to calendar(s) 
expressed in CaTTS). CaTTS complements data modeling 
and reasoning methods designed for generic Semantic Web 
applications such as RDF or OWL with methods specific to 
the particular application domain of calendars and time. 


Categories and Subject Descriptors 


1.2.4 [Artificial Intelligence]: Knowledge Representation 
Formalisms and Methods—representation languages; D.3.1 
[Programming Languages]: Formal Definition and The- 
ory—syntax 


General Terms 
Languages 
Keywords 


time, calendars, types, Web reasoning 


1. INTRODUCTION 


Data referring to cultural calendars such as the widespread 
Gregorian dates but also dates after the Chinese, Hebrew, 
or Islamic calendars as well as data referring to professional 
calendars like fiscal years or teaching terms are omnipresent 
on the Web. Most likely, they will play an essential role on 
the Semantic Web, too. Formalisms such as XML Schema 
have acknowledged this by offering a rather extensive set of 
Gregorian dates and times as basic data types. 
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CaTTS-TDL| CaTTS-FDL 


Figure 1: Languages of CATTS. 


CaTTS-CL 


This article introduces into CaTTS, the Calendar and 
Time Type System that goes far beyond predefined date 
and time types after the Gregorian calendar. CaTTS con- 
sists of two languages, a type definition language, CaTTS- 
DL, and a constraint language, CaTTS-CL, of a (common) 
parser for both languages, and of a language processor for 
each language. 

Using the (type) definition language CaTTS-DL, one can 
specify in a rather simple manner more or less complex, 
cultural or professional calendars [3]. Specificities like leap 
seconds, leap years, and time zones can be easily expressed 
in CaTTS-DL. Calendars expressed in CaTTS-DL are com- 
posable in the sense that the language offers a means for 
modules. Thus, one can extend a standard calendar such as 
the Gregorian calendar used in Germany with a particular 
teaching calendar, e.g. the one of a specific German univer- 
sity. 

CaTTS-DL gives rise to defining both, calendric data types 
specific to a particular calendar — such as “working day”, 
“Easter Monday”, “exam week”, or “CS123 lecture” (defin- 
ing the times when the Computer Science lecture number 
123 takes place) — using the language fragment CaTTS- 
TDL (for Type Definition Language) of CaTTS-DL, and 
data formats for such data types — such as “5.10.2004”, 
“2004/10/05”, or “Tue Oct 5 16:39:36 CEST 2004” — using 
the language fragment CaTTS-FDL (for Format Definition 
Language) of CaTTS-DL. 

The language processor for CaTTS-DL consists of two 
software components, a static type checker and a predicate 
interpreter. Consider a calendar C specified in CaTTS- 
DL and a program P in the language CaTTS-CL, XQuery, 
XSLT or any other program P with type annotations re- 
ferring to types and/or formats specified in the calendar C. 
CaTTS’ static type checker verifies and/or extends the type 
annotations in P generating a type checked version P’ of P: 


calendar C 


ES CaTTS’ static we 
type checker 


type checked version P’ of P 


program P 


Consider a type definition T (e.g. “working day” or “exam 
week”) from a calendar specified in CaTTS-DL and a data 
item D (e.g. “2004/10/05” ). CaTTS’ predicate interpreter 
detects whether the data item D has type T (e.g. whether 
“2004/10/05” is a “working day” or an “exam week” - the 
later being probably false): 


type definition T data item D 


=~. predicate VA 
interpreter 
yes/no 


Both CaTTS-DL and CaTTS-CL provide (the same) pre- 
defined functions (e.g. shift forward and backward, during, 
and usual arithmetics). Using these functions, one can ex- 
press for example, “the second day after working day X” (in 
CaTTS: shift X:working day forward 2 day). 

CaTTS’ type checker can be used for static type checking 
of programs or specifications in any language (e.g. XQuery, 
XSLT, XML Schema), using date formats enriched with type 
annotations after some calendar specified in CaTTS-DL. In 
particular, it is used for the static type checking of temporal 
constraint programs in CaTTS-CL, the constraint language 
of CaTTS. 

Using CaTTS’ constraint language CaTTS-CL, one can 
express a wide range of temporal constraints referring to the 
types defined in calendar(s) specified in the definition lan- 
guage CaTTS-DL. For example, if one specifies in CaTTS- 
DL a calendar defining both, the Gregorian calendar (with 
types such as “Easter Monday” or “holiday” ) and the teach- 
ing calendar of a given university (with types such as “work- 
ing day”, “CS123 lecture”, and “exam week”), then one can 
refer in CaTTS-CL to “days that are neither holidays, nor 
days within an examination week” and express constraints 
on such days such as “strictly after Easter Monday and be- 
fore June”. Thus, using CaTTS-CL one can express real-life, 
Web, Semantic Web, and Web service related problems such 
as searching for train connections or making appointments 
(e.g. for audio or video conferences) over several time zones. 

CaTTS provides with a constraint solver for problems ex- 
pressed in CaTTS-CL. This solver refers to and relies on 
the type predicates generated from a calendar definition in 
CaTTS-DL. This makes search space restrictions possible 
that would not be possible if the calendar and temporal no- 
tion would be specified in a generic formalism such as first- 
order logic and processed with generic reasoning methods 
such as first-order logic theorem provers. 


2. CATTS AND THE SEMANTIC WEB 
CaTTS complements data modeling and reasoning meth- 
ods such as RDF [15] or OWL [14] designed for generic Se- 
mantic Web applications with methods specific to a particu- 
lar application domain, that of calendars and time. CaTTS 
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approach is a form of “theory reasoning” like “paramodula- 
tion”. Like paramodulation ensures natural expressing and 
efficient processing of equality in resolution theorem proving, 
CaTTS makes a user friendly expression and an efficient pro- 
cessing of calendric types and constraints possible. CaTTS 
departs from time ontologies such as the DAML Ontology 
of Time [4] or time in OWL-S [10] as follows: 


e CaTTS considerably simplifies the modeling of speci- 
ficities of cultural calendars (such as leap years, sun- 
based cycles like Gregorian years, or lunar-based cycles 
like Hebrew months), 


e CaTTS provides both, a static type checker and type 
predicates for every CaTTS calendar(s) specification, 


e CaTTS comes along with a constraint solver dedicated 
to calendar definitions that (1) processes CaTTS type 
annotations as constraints and (2) the language of whi- 
ch is amenable to CaTTS static type checking. 


3. CATTS’ MODEL IN A NUTSHELL 


This section is a mathematical prologue that can be skipped 
in a first reading. 

CaTTS’ notion of time is linear. CaTTS is not intended 
for expressing possible futures, hence it is not based on a 
“branching time”. Most common-sense, Web and Semantic 
Web and many Web service application can be conveniently 
modeled in a linear time framework. 

CaTTS’ notion of time is purely interval-based, i.e. tem- 
poral data of every kind have a duration. This reflects a 
widespread common-sense understanding of time according 
to which one mostly refer to time interval, not to time points. 
E.g. one refers to “2004/10/05”, a day, or to “1st week of Oc- 
tober 2004”, a week. Even time point-like data such as 9:25 
can be perceived as having a duration, possibly as small as 
one second or one millisecond. Considering only time inter- 
vals and no time points has two advantages. First, it signif- 
icantly simplifies data modeling, an advantage for CaTTS’ 
users. Second, it simplifies data processing, i.e. static type 
checking and constraint reasoning, an advantage for CaTTS’ 
language processors. However, CaTTS can deal with time 
point-like data like the beginning of a week or whether a day 
d falls into a week w or not, as well. 

In order to formalize CaTTS (time point-less) model, how- 
ever, time points have to be considered: 


Definition 1. A base time line is a pair (T,<7) where 
T is an infinite set (isomorphic to R) and <r is a total order 
on T such that T is not bounded for <y. An element t of 
T is called time point. 


Each CaTTS type definition creates a discrete image of 
the time line since CaTTS data types define data items with 
durations. E.g. data types “day” and “working day” imply 
two (different) images of the time line: days partition the 
time line, working days correspond to a portion of the day 
partition of the time line. Both images of the time line are 
discrete, i.e. isomorphic to Z. The notion of time granularity 
[2] formalizes such “discretizations” of the time line: 


Definition 2. Let (IT,<r) be a base time line. Let G = 
{gi | i € Z} bea set isomorphic to Z. Let’s call the elements 
of G granules. A time granularity is a (non-necessarily 
total) function G from G in the set of intervals over 7 such 
that for all i j € Z with i < j 


1. if G(g:) #0 and G(g;) # 0 , then for all t: € G(g:) and 
for all t; E€ G(g;) ti <7 tj. 


2. If G(gi) = Ú, then G(g;) = 9. 


Examples of granules are days, working days, weeks, mon- 
ths, holidays, etc. According to Definition 2, two different 
granules of a same time granularity do not overlap. The 
first condition of Definition 2 induces from the ordering of 
the time points (of the base time line) the common-sense 
ordering on granules: e.g. the day “10/25/2004” is after the 
day “10/24/2004”. The second condition of Definition 2 is 
purely technical: it makes it possible to refer to the infinite 
set Z also for finite sets of granules (e.g. someone’s exam 
days during his/her years of study). 


Definition 3. Let G be a time granularity and gi,g; E G 
granules. 
A duration D over G is a number (expressed as an unsigned 
integer) of granules of G. 


Thus, a duration can be informally understood as a time 
interval over a granularity with a given length but with no 
specific starting or ending point. 

Subtypes are defined in CaTTS in terms of either inclu- 
sion or aggregation of time granularities. E.g. a type “work- 
ing day” is an inclusion (in the common set-theoretic sense) 
of the type “day” since the set of working days is a subset 
of the set of days; the type “week” is an aggregation (in 
constructive set-theory) of the type “day” since each week 
can be defined as a time interval of days. 


Definition 4. Let G and H be time granularities. G is 
an aggregation subtype of H, denoted G < H, if every 
granule of G is an interval over H and every granule of H is 
included in (exactly) one granule of G. 


Definition 5. Let G and H be time granularities. G is an 
inclusion subtype of H, denoted G C H if every granule 
of G is a granule of H. 


The two subtype relations, inclusion subtype and aggre- 
gation subtype, are corner stones of CaTTS that, to the 
best of the knowledge of the authors, have not been pro- 
posed elsewhere. As the examples given below show, they 
are very useful in modeling calendars. Indeed, they reflect 
widespread forms of common-sense reasoning with calendric 
data. 

Note that < U C is an order relation on time granularities. 
<x U C is defined as follows: Gi < U C G2 iff Gi < Go 
or Gi C G2. The following formalization of the notion of 
“calendar” reflects the central role played by aggregation 
and inclusion subtyping in CaTTS: 


Definition 6. A calendar C = {Gi,...Gn} is a finite set 
of time granularities such that there exists a G; € C and for 
all Gj € C, i,j € {1...n} and i # j Gj is < U C-comparable 


The subsequently illustrated set of time granularities de- 
fines a calendar; each of the time granularities is < U C- 
comparable with the time granularity “second”. 


+ month 
mr A ai 
millisecond —— second ——— day ——>—— week 
B] 


working-day 
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-4 -3 -2 -1 0 1 23 4567 8 910 
AAAA 


—— aoe 2 weekend 
ie E week 
0. A 3, weekend_day 
al eee i sunday 
0 1 saturday 


day 


Figure 2: Indexing of the types defined in Section 4 (day(1) 
is Thursday, January 1, 1970). 


4. CATTS-DL: DEFINITION LANGUAGE 


Recall that CaTTS’ definition language, CaTTS-DL, con- 
sists of a type definition language, CaTTS-TDL, and a date 
format definition language, CaTTS-FDL. 

CaTTS-TDL provides a set of type constructors for declar- 
ing time granularities as subtypes (of predefined or user- 
defined) types in terms of predicates, called predicate sub- 
types. A subtype in CaTTS specifies (in terms of a pred- 
icate) a set, referred to as “predicate set”. The usual set- 
theoretic operations (e.g. U) can be applied to predicate sets. 
In CaTTS, calendars (cf. Definition 6) are themselves typed 
by calendar signatures. This makes CaTTS calendar spec- 
ifications reusable, maintainable, and easy to extend. In 
addition, user-definable calendar functions can be specified 
in CaTTS that parameterize calendars. Such functions pro- 
vide a means to specify different calendar versions all having 
the same calendar signature. CaTTS-FDL provides a means 
to specify specific constants, i.e. the data items of predicate 
subtypes defined in a CaTTS-TDL calendar definition. 


4.1 Reference Time 


Each CaTTS implementation has a single predefined (base) 
type called reference.' reference is a time granularity 
such as “second” or “hour”, chosen e.g. depending on the 
operating system. If the type reference is used in a CaTTS- 
DL calendar specification, then all other (user-defined) types 
are expressed directly or indirectly in terms of reference, 
using CaTTS’ aggregation and/or inclusion subtyping (cf. 
Section 3). Note that the use of reference is optional 
in some CaTTS-DL calendar specification. If reference 
is e.g. the time granularity “second”, a convenient choice 
with the Unix operating system, then one can specify (us- 
ing CaTTS-DL) further coarser time granularities such as 
“day”, “week”, and “year” as well as finer time granulari- 
ties such as “millisecond”. The reference type makes conver- 
sions among any other types defined in a CaTTS-DL calen- 
dar specification (in terms of aggregation and/or inclusion), 
and, thus, between different CaTTS-DL calendars possible. 

In CaTTS’ prototype implementation, reference is the 
time granularity “second” of Unix (UTC seconds with mid- 
night at the onset of Thursday, January 1 of year 1970 (Gre- 
gorian) as fixed point indexed by 1). 

In CaTTS-DL, one defines a type finer than that of refe- 
rence as follows: 
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type millisecond = refinement 1000 @ reference (1); 


The type (time granularity) millisecond is defined as a 
thousandth refinement of a second (recall reference is the 


lreference is a base type, because it has no internal struc- 
ture as far as the type system of CaTTS is concerned. 

In this and the following examples, type identifiers start 
with lower case letters. 


time granularity “second”). The type millisecond is an- 
chored at (denoted @) second 1 (denoted reference(1)), 
since millisecond(1) is the first millisecond in the interval 


of milliseconds specifying the first second (i.e. reference (1)). 


Thus, in CaTTS types such as reference or millisecond 
induces clear integer indices of its data items. This indexing 
of data items turns out to be extremely useful in practice 
(cf. below). 


4.2 Predicate Subtypes 


Infinite sets are logically encoded by predicates: for any 
set A, the predicate p : A — B defines the set of those 
elements of A that satisfy p. Such sets are called predi- 
cate sets. In type theory, predicate sets are interpreted as 
predicate subtypes, particularly used to express dependent 
function types [11]. CaTTS uses predicate subtypes in a 
different manner and not for theoretical, but instead prac- 
tical purposes. 

CaTTS uses predicate subtypes as a means to define cal- 
endric types. E.g. one can describe the time granularity 
“week” as the subset of those time intervals over the time 
granularity “day” having a duration of 7 days and beginning 
on Mondays. This can be directly expressed in CaTTS-DL 
as follows: 


type week aggregate 7 day @ day(—2); 


The type week is an aggregation of days such that each data 
item is an interval with duration “7 days”. The first week 
(i.e. week(1)) is anchored at (denoted @) day(-2), i.e. the 
first day of the interval of days aggregated to the data item 
week(1). Since day(1) is a Thursday (recall that CaTTS’ 
implements Unix time with Thursday, January 1, 1970 as 
fixed point indexed by 1), day(-2) is a Monday. Any fur- 
ther index can be computed relative to this anchor (cf. Fig- 
ure 2). Thus, the predicate subtype week:day — B speci- 
fies the infinite set of those day time intervals satisfying the 
predicate “week” as previously expressed in CaTTS-DL. The 
type week is an aggregation subtype of the type day (cf. Def- 
inition 4), written week <: day in CaTTS’ syntax, and read 
as “week is an aggregation of day”. In CaTTS-DL, aggre- 
gation subtypes are constructed by the aggregate construc- 
tor, or by the predicates “#<” (“coarser restriction”) and 
“#>” (“finer restriction”), set-based operations defined for 
CaTTS due to predicative set aggregation. E.g. aggregating 
the type weekend_day into the type week yielding the type 
weekend, a coarser restriction of week to weekend_day. The 
two set-based aggregation predicates may also be used to de- 
fine types having non-convex data items like “working_week” 
(a coarser restriction of working days, i.e. days that are nei- 
ther weekend days nor holidays, into weeks). Note that one 
might define aggregations having data items of different du- 
rations involving often complex conditions (e.g. Gregorian 
or Hebrew months), as well. 

One can describe the time granularity “weekend day” as 
the subset of those granules of time granularity “day” that 
are either Saturdays or Sundays. This can be directly ex- 
pressed in CaTTS-DL as follows: 


type saturday 


= select day(i) where 
relative i in week == 6; 
select day(i) where 
relative i in week == 7; 
saturday | sunday; 


type sunday 


type weekend_day 


The type saturday is a selection of the 6** day relative in 
each week. Thus, the predicate subtype saturday:day — B 


705 


calendar type STD = 


sig 
type second; 
type minute <: second; 
type hour <: minute; 
type day <: hour; 
type week <: day; 
type month <: day; 
type year <: month; 
group day-of_week c: day; 
type weekend_day c: day; 
group holiday c: day; 


end 


Figure 3: Signature of a standard calendar in CaTTS-DL. 


specifies the infinite set of those days satisfying the predicate 
“saturday” as previously expressed in CaTTS-DL. In the 
same manner, the type sunday is defined. Finally, the type 
weekend_day satisfies either the predicate of type saturday 
or (denoted “|”) the predicate of type sunday. The types 
saturday, sunday, and weekend_day are inclusion subtypes 
of the type day (cf. Definition 5), written e.g. weekend_day 
c: day in CaTTS’ syntax, and read as “weekend day is an 
inclusion of day”. In CaT'TS-DL, inclusion subtypes are con- 
structed by the select constructor by specifying a predicate 
as a combination of any operation predefined in CaTTS (cf. 
Appendix A for the complete syntax of CaTTS) following 
the reserved word where, or by a set-based constructor: “|” 
(“or”), “&” (“and”), and “\” (“except”), in fact ordinary 
set operations interpreted as predicate subtype constructors 
in CaTTS-DL. As illustrated in Figure 2, the indexing of in- 
clusion subtypes is successive. The indexing of any inclusion 
subtype is however implicitly related to that of its inclusion 
supertype, appropriately choosing the data item indexed by 
0 relative to that one of the supertype. 

Note that weekend days may alternatively be defined as a 
group, i.e. anamed collection of type definitions in CaTTS- 
DL: 


group weekend_day = 
with select day(i) where (relative i 
type saturday where j 
type sunday where j 


in week)==j 


end 


Having defined the group weekend_day, one can either refer- 
ring to data items of the group weekend_day, or, more spe- 
cific, to data items of one of the types (saturday, sunday) 
defined within the group, explicitly defined belonging to a 
less specific “kind”, i.e. a group of a CaTTS’ type. 

Furthermore, CaTTS provides a polytypic constructor: 
| 7 | (durations of 7) that describes for any type 7 a duration 
(cf. Definition 3) whose data items are drawn from 7. For 
example, |day| is the type of durations of days. 

Note that CaTTS’ type constructors provide a natural 
way to obtain periodic events, e.g. the C5123 lecture of- 
fered within the summer term 2004 (referred to as ST04) (in 
CaTTS X:CS123_lecture during ST04) of type CS123_lec- 
ture. Note that periodic events are very frequently consid- 
ered in current research. The authors believe that CaTTS 
offers a particularly convenient and intuitive manner to spec- 
ify periodic events. 


import LeapSeconds; 
calendar Gregorian:STD = 
cal 
type second 
type minute 
alternate 
| i 1051200 (*1.1.1972*) —> 70 second 
| hasLeapSec?(i) —> 61 second 
| otherwise —> 60 second 
end @ second(1); 
type hour aggregate 60 minute @ minute(1); 
day aggregate 24 hour @ hour(1); 
week aggregate 7 day @ day(-—2); 
month aggregate month(i) 
day named january , 
alternate 
|((i div 12)-—1970) mod 4 == 0 && 
(((i div 12)—1970) mod 100 != 0 || 
((i div 12) —1970) mod 400 == 0) —> 29 day 
| otherwise —> 28 day 
end named february , 
day named march, 
day named april , 
day named may, 
day named june, 
day named july, 
day named august, 
day named september, 
day named october , 
day named november, 
day named december @ day(1); 
type year = aggregate 12 month @ month(1); 
group day-of_week 
with select day(i) where 


reference ; 
aggregate minute (i) 


(relative i in week) == j 
type monday where j == 1 
type tuesday where j == 2 
type wednesday where j == 3 
type thursday where j == 4 
type friday where j == 5 
type saturday where j == 6 
type sunday where j == 7 
end 
type weekend_day = saturday | sunday; 
group holiday = with select day(i) where 
(relative i in M) == j 
type all-saints where j == 2 for M = november 
type christmas where j == 25 for M = december 
end 
end 


Figure 4: The Gregorian calendar in CaTTS-DL. 


4.3 Calendar as Type 


The basic entities of CaTTS-DL calendar definitions (cf. 
Definition 6) are calendars, calendar signatures, and calen- 
dar functions. 


4.3.1 Calendars 


A calendar is a packaged, finite collection of CaTTS type 
definitions and calendar specifications, assigning types to 
type identifiers, groups to group identifiers, and calendars 
to calendar identifiers, similar to ML structures [9] or XML 
documents [13]. The types and calendars specified in a cal- 
endar are delimited by the keywords cal and end. The fol- 
lowing specification binds a calendar to the identifier Cal. 
This calendar defines an environment mapping day, weeken- 
d_day, week, and weekend to their respective group and 
type definitions. 


calendar Cal = 
cal 
type day; 
group weekend_day 


with select day(i) where 
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(relative i in week) = 
type saturday where 
type sunday where 

end 

type week = aggregate 7 day @ day(0); 
type weekend week #< weekend-day ; 
end 


Note that day is a user-defined reference type (isomorphic to 
the integers) without any further specifications. The identi- 
fiers in a calendar are qualified. For example, the qualified 
identifier Cal.week refers to the component week in the cal- 
endar definition Cal. 


4.3.2 Calendar Signatures 


Calendar signatures are kinds of “types” for calendars de- 
fined in CaTTS-DL, similar to ML [9] signatures or XML 
Schema declarations [12]. Calendar signatures specify iden- 
tifiers and abstract predicate subtypes in terms of inclusion 
or aggregation supertypes for each of the components of a 
calendar implementing the signature. The following specifi- 
cation binds a calendar signature to the identifier SIG. 


calendar type SIG = 
sig 
type day; 
group weekend-_day c: 
type week <: day; 
type weekend c: weekend day; 
end 


day ; 


This calendar signature describes those calendars having a 
type day, a group weekend_day, where each type belong- 
ing to must be an inclusion subtype of day and types week 
as aggregation subtype of day and weekend as aggregation 
subtype of weekend_day. Since the calendar Cal introduced 
above satisfies this calendar signature, it is said to match 
the calendar signature SIG. Note that a defined calendar 
usually matches more than one calendar signature, and vice 
versa, a calendar signature may be implemented by more 
than one calendar. Calendar signatures in CaTTS-DL may 
be used to define views of calendars due to ascription, i.e. 
specifying less components than implemented in any match- 
ing calendar. The non-specified components are thus local 
to its calendar specification. 


4.3.3 Calendar Functions 


Calendar functions are user-defined functions on calen- 
dars using a syntax similar to function declarations in many 
programming languages. A calendar function CF defining 
Hebrew weekend days can be declared in CaTTS as follows: 
cal_fun CF(C:SIG):SIG = 

cal 
group weekend_day 
where (relative i in C.week) == j 


type friday where j 
type saturday where j 


with select C.day(i) 


aa] 


end 
end 


The calendar function CF takes as argument any calendar C 
matching the calendar signature SIG, and yields as result 
a calendar also matching SIG. When applied to a suitable 
calendar, the calendar function CF yields as result the calen- 
dar whose group weekend_day is that of (Hebrew) weekend 
days, i.e. Fridays and Saturdays. Furthermore, any type 
definition in C depending on that of weekend_day is changed 
respectively to the calendar function CF when applied to C. 
E.g. applying CF to the previously illustrated calendar defi- 
nition Cal yields a “new” group weekend_day and the type 


weekend is changed, as well. Since the calendar function 
CF may be applied to any calendar matching the signature 
SIG, the function is polymorph, thus define a parameterized 
calendar. 


4.4 CaTTS-FDL 


With most applications, one would appreciate not to spec- 
ify dates and times using indices of the data items of CaTTS 
types like day(23) or second(-123), but instead date for- 
mats like “5.10.2004”, “2004/10/05”, or “Tue Oct 5 16:39:36 
CEST 2004”. CaTTS-FDL provides a means for defining 
date formats. 

A CaTTS-FDL date format is defined by a sequence of 
string constants and/or placeholders, the latter appearing 
as variable names optionally followed by a representation 
descriptor. Consider the following example: 


format stdfmt:day = y "-" m "-" d where 
stdfmt within year(y), 
stdfmt within M:month, 
m == relative index M in year, 


d == relative index stdfmt in month; 


This CaTTS-FDL format specification binds the identifier 
stdfmt to a standard format for data items of type day. 
Both a parser and a render function (i.e. String — day as 
well as day — String) can be computed by resolving the 
constraints associated with stdfmt. Given “1970-1-1”, we 
get that y = 1970, m = 1 and d = 1 and can thus solve the 
constraints to get e.g. Gregorian.day(1). Vice versa, given 
(Gregorian.)day(1), we find that it is within year (1970), 
within M, which is equal to month(1) and is the 1% in a 
year, and that day(1) is the 1% in a month, yielding the 
same values for y, m and d as above. 

Catalogs are collections of formats specifying to which cal- 
endar signature these formats can be applied. Such catalogs 
may be nested, applying to common scoping rules. 


catalog ISO: STD = 


cat 
(* nested catalog for extended ISO formats x) 
catalog Extended = 
cat 
format stdfmt:day = y "-" m "-" d where 
stdfmt within year(y), 
stdfmt within M: month, 
m == relative index M in year, 
d == relative index stdfmt in month; 
end 
end 


As with calendars, identifiers defined within a catalog are 
qualified, e.g. ISO.Extended.stdfmt is the full name of the 
above format. Date formats specified in CaTTS-FDL may 
be imported into a program in the language CaTTS-CL, 
XQuery, or any other language using calendric data typed 
after CaTTS-DL calendar specifications by CaTTS’ import 
mechanism for formats use_format . 


4.5 Use Case: Specifying Calendars 


To express and find solutions to real-life, Web, Seman- 
tic Web, and Web Service related problems such as train 
scheduling or making appointments, context-dependent se- 
mantics considering both cultural and professional calendars 
and time zones is necessary. 

Consider the following scenario: A Munich-based business 
man needs to schedule a phone conference with a colleague 


3If none is given, that portion of the format is interpreted 
as a variable-length unsigned integer. 
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in Tel Aviv. Besides the various constraints to schedule 
the phone conference, the business men use different calen- 
dars. Both use the Gregorian calendar to schedule every- 
day times and dates, but shifted according to different time 
zones. The Tel Aviv-based business man uses the Hebrew 
calendar for holidays to be considered, but, for the same 
reason, the Munich-based business man uses the Gregorian. 

The CaTTS-DL calendar signature in Figure 3, assigned 
to the identifier STD, describes standard calendar types and 
groups matched by most calendars. second is a non-further 
specified type identifier. 

The calendar definition given in Figure 4 binds a calen- 
dar to the identifier Gregorian such that this calendar must 
match the calendar signature STD (denoted Gregorian:STD). 
CaTTS allows for importing external libraries using the re- 
served word import. The calendar Gregorian imports a li- 
brary LeapSeconds, containing, among other things, a boole- 
an function hasLeapSec? over minutes. Leap second in- 
sertion into UTC-time (recall that reference is the time 
granularity of UTC-seconds) started in 1972 (Gregorian); 
10 leap seconds have been inserted into the first minute of 
the year 1972. In the present CaTTS-DL modeling, the in- 
dex of this minute is directly referred to. The type identifier 
second is assigned to the predefined base type reference. 
The rules for the Gregorian leap month February are ex- 
pressed by a suitable combination of operations predefined 
in CaTTS. The predefined arithmetic function relative i 
in M (used in the group holiday) selects specific data items 
i of type day relatively located to each data item in type 
M, a local macro variable substituted by a CaTTS-DL type. 
Any further type definition is straightforward following the 
rules of the Gregorian calendar [5]. 

The calendar definition given in Figure 5 binds a calen- 
dar to the identifier Hebrew such that this calendar must 
match the calendar signature STD (denoted Hebrew:STD). 
The Hebrew day “23 Tevet 5730”, a Wednesday (yom re- 
vii) is the day corresponding to the Unix epoch (“1 Jan- 
uary 1970” (Gregorian)). To implement an alignment of 
Hebrew regaim* and halaqim® (Hebrew partitions of hours) 
with CaTTS’ reference type a respective shift (denoted by 
the definition of ref) is defined. The type identifiers second 
and minute are used to match the Hebrew calendar with the 
standard signature STD°. Note that Hebrew weeks start on 
Sundays (yom rishon), and that the first month in any He- 
brew year is Tishri. Since Hebrew leap year computations 
depend on the Metonic cycle aligning 19 sun-based years to 
235 lunar-based months, the index 1 for Hebrew months is 
respectively moved form “Tevet 5730” to “Nisan 5720” by 
resetting this month’s index (133) relatively to the index 1 
(denoted ~@133). To simplify the modeling of the Hebrew 
calendar in CaTTS-DL, the library HebrewLeapYear, con- 
taining the various functions (e.g. isLeapAdarRishon? and 
isHebrewLeapYear?) used in the present calendar specifica- 
tion is imported. Such functions may however be directly 
specified within a CaTTS-DL calendar definition by a user- 
defined “macro”. E.g. isLeapAdarRishon? (i.e. the sec- 
ond to last month in a Hebrew year which depends on the 


“Plural of rega. 

5Plural of heleq. 

®Whether such an alignment of the Hebrew calendar to the 
STD calendar signature is appropriated or not, does not have 
to be discussed here. The present example aims at showing 
that it is possible and easy to express with CaTTS. 


Metonic cycle) can be specified by the following two CaTTS- 
DL macros: 


macro isLeapAdarRishonInCycle?(i) 
Les 396. |) =s ya jii 
Ii i == 209 || 
macro isLeapAdarRishon ?(m) 
isLeapAdarRishonInCycle?((m mod 235) + 1); 


All rules implement in the CaTTS-DL definition of the He- 
brew calendar are those suggested in [5]. 

Note that only a few Gregorian and Hebrew holidays are 
specified with the two present CaTTS-DL calendars. Fur- 
ther can be similarly specified in CaTTS-DL. 

Since reference is UTC-time and since UTC-time is ad- 
justed to the time zone Greenwich Mean Time (GMT), the 
previously mentioned calendars Gregorian and Hebrew cor- 
respond to this time zone. Any further calendar C matching 
also the calendar signature STD, but which refers to other 
time zones can be expressed by a (user-defined) calendar 
function, redefining the definition of type day by choosing 
suitable anchors for the considered time zones (cf. Figure 
6). If the calendar function EET is applied to the calendar 
Gregorian or Hebrew, then any (aggregation or inclusion) 
subtype of day is respectively changed. 


5. CATTS-CL: CONSTRAINT LANGUAGE 


CaTTS-CL, CaTTS’ constraint language, is statically ty- 
ped after CaTTS-DL type definitions. CaTTS-CL is a lan- 
guage to declaratively express a wide range of temporal 
and calendric constraint problems. Such problems are then 
solved by CaTTS-CL’s constraint solver. Given a CaTTS- 
DL specification of the Gregorian calendar (with types such 
as “weekend day”) and the teaching calendar of a given 
university (with types such as “exam week”), one can re- 
fer in CaTTS-CL programs to weekend days. One can fur- 
ther express constraints on such days such as “after exam 
week” and “before June 2004” (assuming that the used date 
formats are specified in CaTTS-FDL). This problem is ex- 
pressed in CaTTS-CL as follows: 


X:weekend_day && X after Y:exam_week && 
X before "2004-06"" 


The constraint variable X ranges over values of type weekend- 
-day and Y over exam_week. The constraints “after an ex- 
amination week” (in CaT'TS-CL X after Y:exam_week) and 
“before June 2004” (in CaTTS-CL X before "2004-06") 
are straightforwardly expressed as illustrated. The con- 
straints of CaTTS-CL are given in Appendix A. 

CaTTS-CL provides function symbols for data items of 
types defined in CaTTS-DL, value constructors for time in- 
tervals and durations, arithmetic functions, and condition- 
als. CaTTS-CL’s constraint symbols are common equation 
symbols, Allen’s 13 interval relations [1], and the symbol “:” 
for type annotations. The complete syntax (of all CaTTS 
language fragments including CaTTS-CL) is given in Ap- 
pendix A. 

The constraint X:7 assigns to a variable X a finite do- 
main over values of type 7 (defined in CaT'TS-DL). Note 
that the function symbols provided with CaTTS-CL are es- 
sentially the same as those provided with CaTTS-DL. Fur- 
thermore, the constraint symbols provided with CaTTS-CL 


"In this and the following examples, constraint variables 
start with capital letters. 
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import HebrewLeap Year; 

calendar Hebrew:STD = 

cal 
type 
type 
type 
type 


-ref = refinement 114 @ reference (—43199); 
second aggregate 5 -ref; 
rega second; 
minute aggregate 76 second; 
heleq minute; 
hour aggregate 1080 minute; 
type day aggregate 24 hour; 
week aggregate 7 day @ day(-—2); 
month aggregate month(i) 
named nisan, 
named iyyar , 
named sivan, 
named tammuz, 
named av, 
named elul , 
30 day named tishri , 
alternate 
new YearDelay(i) 
—> 30 day named 
otherwise —> 29 day named 
end named marheshvan , 
alternate 
newYearDelay(i) > 0 
—> 30 day named 
otherwise —> 29 day named 
end named kislev , 
29 day named tevet , 
30 day named shevat , 
alternate 
isLeapAdarRishon?(i) —> 30 day 
named adar-rishon 


d 
d 
d 
d 
d 
d 


long-marheshvan 
short-marheshvan 


long-kislev 
short -kislev 


otherwise none 
end, 
29 day named adar-sheni @ day(—21) “@ 133; 
type adar adar-rishon | adar—sheni; 
type year aggregate 
alternate year(i) 
| isHebrewLeapYear?(i) —> 13 month 
| otherwise —> 12 month 
end @ month(7) ~@ 5730; 
group day-of_week = 
with select day(i) where 
(relative i in week) == 
type yom-rishon where 
type yom-sheni where j = 
type yom-shelishi where 
type yom-revii where j 
type yom_hamishi where 
type yom-shishi where j 
type yom-_shabbat where j == 7 
end 
type weekend_day 


j 
j 


jai 


= yom-shishi | yom-shabbat ; 
group holiday with select day(i) where 
(relative i in M) == j 
type yom_kippur where j == 10 for M = tishri 
type passover where j == 15 for M = nisan 
end 
end 


Figure 5: The Hebrew calendar in CaTTS-DL. 


(*CET: Central European Time, GMT + 1, Munichx) 


calendar_function CET(C:STD) STD = 

m day = aggregate 24 C.hour @ C. hour (2); 
Ee eee European Time, GMT + 2, Tel Avivx) 
calendar_function EET(C:STD) STD = 

Pees day = aggregate 24 C.hour @ C. hour (3); 
end 


Figure 6: Calendars in different time zones in CaTTS-DL. 


have the same names as the predicate symbols provided 
with CaTTS-DL because type defining predicates and con- 
straints are both boolean functions. However, there is an 
elementary difference between a CaTTS-CL constraint and 
a CaTTS-DL predicate: a constraint specifies the proper- 
ties and relationships among partially unknown “objects”. 
All possible solutions satisfying the constraint are computed 
by the constraint solver. In contrast, a predicate specifies 
the condition(s) to be satisfied by the elements belonging 
to some predicate subtype. E.g. the type defining predicate 
“holiday” specifies the infinite set of all holidays, and the 
constraint “X:holiday” computes the (infinite) set of all hol- 
idays. Thus, the values satisfying any CaTTS-CL constraint 
are computed, whereas a predicate only specifies the infinite 
set of values of some CaTTS-DL predicate subtype without 
performing any computations. 

A CaTTS-CL program is a finite collection of CaTTS-CL 
constraints. Calendars defined in CaTTS-TDL are referred 
to by the use_calendar construct, data formats defined in 
CaTTS-FDL are referred to by the use_format construct, 
and external libraries are referred to by the import con- 
struct. The constraints specified in a CaTTS-CL program 
are delimited by the reserved words prog and end. 


5.1 Use Case (Continued): Multi-Calendar 
Appointment Scheduling 


Turning attention back to the two business men schedul- 
ing a phone conference (cf. Section 4.5) during the 1st week 
in October 2004, they specify the necessary constraints in 
a CaTTS-DL program (cf. Figure 7). The day, the phone 
conference might take place should be a Monday, Tuesday, 
Wednesday, or Thursday in Tel Aviv. The conference itself 
(denoted by the variable Conf) has a maximal duration of 1 
hour, and it should be between 9 a.m. and 5 p.m. consider- 
ing both time zones involved in this scenario. Furthermore, 
the telephone conference should take place in the first week 
of October 2004. 


6. STATIC TYPE CHECKING AND 
CONSTRAINT REASONING 
SUMMARIZED 


This section briefly summarizes the characteristics of 
CaTTS’ language processors. A static type checker to en- 
sure the behavior and semantics of calendric data and con- 
straints, and a constraint solver to reason with such data. 


6.1 Static Type Checker 


In programming languages such as ML [9] static type 
checking is used as a “lightweight formal method” (i.e. merely 
syntactically tractable) for program analyses ensuring cor- 
rect behavior of programs and/or systems w.r.t. some spec- 
ification. CaTTS, however, uses static type checking for 
semantic restrictions of inherent ambiguous and/or impre- 
cise calendric data and constraints ensuring correct inter- 
pretation of CaTTS-CL programs w.r.t. some CaTTS-DL 
calendar specification. For space reasons, the typing and 
subtyping relations of CaTTS’ static type checker cannot 
be presented in this article. First experimental results with 
a prototype implementation of CaTTS’ type checker point 
to a good efficiency (i.e. type checking is polynomial). Fur- 
ther investigations concerning efficiency as well as soundness 
and completeness results are undergo. 
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6.2 Constraint Solver 


CaTTS’ constraint solver essentially works on arbitrary 
finite domains with type annotations after calendars defined 
in CaTTS-DL. It departs from constraint systems over finite 
domains [6] due to (i) typed constraint variables, and (ii) 
constraint variables that may range either over single values 
or over intervals of values; thus, reasoning over (possibly 
periodic) intervals. The constraint solver refers to and relies 
on the type predicates generated from a calendar definition 
in CaTTS-DL. This makes search space restrictions possible, 
and furthermore, obtains the semantics of calendric data and 
constraints introduced with CaTTS-DL type definitions. 


7. RELATED WORK 


CaTTS complements data type definition languages and 
data modeling and reasoning methods for the Semantic such 
as XML Schema [12], RDF [15], and OWL [14]: XML Schema 
provides a considerably large set of predefined time and date 
data types dedicated to the Gregorian calendar whereas 
CaTTS enables user-defined data types dedicated to any 
calendar. RDF and OWL are designed for generic Seman- 
tic Web applications. In contrast, CaTTS provides with 
methods specific to particular application domains, that of 
calendars and time. 

CaTTS departs from time ontologies such as the KIF time 
ontology [8], time in OWL-S [10], and the DAML time on- 
tology [4], in many aspects. 

CaTTS considerably simplifies the modeling of specifici- 
ties of cultural calendars (such as leap years, sun-based cy- 
cles like Gregorian years, or lunar-based cycles like Hebrew 
months) as well as the modeling of professional calendars of- 
ten involving “gaps” in time (e.g. “working day”), “gapped” 
data items (e.g. data items of type “working week”), and 
periodic events (e.g. “CS123 lecture”) due to predicate sub- 
types. 

The well-known advantages of statically typed languages 
such as error detecting, language safety, efficiency, abstrac- 
tion, and documentation whereas the two latter obtain par- 
ticular interest due to overloaded semantics of calendric data 
apply to CaTTS, as well. Beyond this, CaTTS’ static type 
checker provides both meta-type checking of predicate sub- 
type definitions in CaTTS-DL and type checking of con- 
straints in CaTTS-CL, obtaining the semantics of different 
time granularities even for reasoning with their granules. 

CaTTS comes along with a constraint solver dedicated 
to calendar definitions in CaTTS-DL; this dedication makes 
considerable search space restrictions, hence gains in effi- 
ciency, possible. 

While (time) ontologies follow the (automated reason- 
ing) approach of “axiomatic reasoning”, CaTTS is based 
on a (specific) form of “theory reasoning”, an approach 
well-known through paramodulation. Like paramodulation 
ensures efficient processing of equality in resolution theo- 
rem proving, CaTTS provides the user with convenient con- 
structs for calendric types and efficient processing of data 
and constraints over those types. 

CaTTS inherently differs from specification languages for 
temporal expressions in natural language text like TimeML 
[7]. TimeML is a language for annotating temporal informa- 
tion in text corpora whereas CaTTS is designed as a type 
language specialized in calendar and time modeling and rea- 
soning, for Semantic Web applications and Web Services. 


program TelConference = 

use_calendar unqualified Gregorian; 
use_calendar Hebrew, CET(C), EET(C); 
use_format unqualified ISO. Extended; 


prog 
Conf:hour during X: week && X during 
relative 
relative 
relative 
relative 


index Conf in CET 
index Conf in 


"2004-10" && relative index X in october == 1 && 
index Conf in CET(Gregorian).day >=9 && 
(Gregorian ). day <= 17 && 
EET( Gregorian ). day >= 9 && 
index Conf in EET( Gregorian ).day <= 17 && 


Conf during EET( Gregorian ).(monday| tuesday | wednesday| thursday ) 


end 


Figure 7: A scheduling problem in CaTTS-CL. 


8. CONCLUSIONS 


This article has introduced CaTTS, consisting of 
e CaTTS-DL, a definition language, itself consisting of 


— CaTTS-TDL, a type definition language and 
— CaTTS-FDL, a date format definition language 


e CaTTS-CL, a constraint language typed by CaTTS- 
DL definitions. 


CaTTS’ predicate subtype constructors allow for defining 
arbitrary time granularities as types in CaTTS-DL. The two 
subtype relations aggregation subtype of and inclusion sub- 
type of provide means for conversions between those types 
during constraint reasoning with calendric data of those 
types, particularly in CaTTS-CL. CaTTS’ polytypic con- 
structors provide a convenient and intuitive manner to spec- 
ify periodic events. Interpreting calendars as types and their 
parameterization ensures maintenance and reuse of calen- 
dars, where the “type” of a calendar provides a summary of 
that calendar. 

CaTTS facilitates the modeling and efficient processing 
of calendar and time data in Web and Semantic Web appli- 
cations and Web Services, especially compared to ontology- 
based modeling and reasoning. 
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APPENDIX caldcl cal decls: 
dcl declaration 
A. SYNTAX OF CATTS calendar calbind calendar 
empty 
caldcl;caldcl sequential 
A.1 Identifiers calbindin: cal: birds: 
t € TyVar type identifiers long dalens eSCSige) 9m cala dikeris: 
c € Calld calendar identifiers long cal caldcl end generatie 
s € CalSigld calendar signature identifiers longc identifier 
f € CalFunld calendar function identifiers f(cale) Funsäppl 
p € Progld program identifiers 
k : ` fdcl ::= fun decls: 
For each class of identifiers X marked “long” there is a cal_fun fbind generatios 
class longX of long identifiers; if x ranges over X then longx empty 
ranges over longX. The syntax of the long identifiers is given fdcl;fdcl sequential 
by the following: fbind ::= fun binding: 
longx ::= long identifiers: f(c:s):s’ = cale 
x identifier 
Cl. <.. .Cn.X qualified identifier n > 1 sigdcl s decls: 
calendar type sigbind generative 
The long identifiers constitute a link between declarations ; ; empty 
and calendars. sigdcl;sigdcl sequential 
sigbind :: s bindings: 
s = sige 
A.2 Grammar sige ::= s exprs: 
sig spec end generative 
CaTTS grammar, including the syntactic forms for both s identifier 
language formalisms CaTTS-DL and CaTTS-CL is given in spec ::= specs: 
a BNF-like notation ((...)denote n < 0 repetitions). type t <: ty aggregation 
erie exprs: type t c: ty inclusion 
k constant group t c: ty group 
n ty duration, n € IN calendar c:sige calendar 
bin0p e e binary op spec; spec sequential 
unOp e unary op 
alternate x:ty <| e — e) alternate pdel ::= p decls: 
ce constraints ce constraint 
ce ::= constraints: use_calendar 
x variable (unqualified) 
x:ty domain constraint longcı ...longcn; nil 
ce iRel ce interval relation import 
ce aRel ce arithm. relation (unqualified) 
ce && ce conjunction lib; ...libn; n21 
use_format 
binOp ::= shift forward | shift backward | (unqualified) 
relative to | + | — | relative in | cate, ...caten ; nzi 
* | \ | mod | div | max | min program pbind generative 
unOp ::= duration_of | begin_of | end_of | index empty : 
iRel ::= equals | before | after | starts | ; pdel;pdel sequential 
started_by | finishes | finished_by | phind > p binds: 
during | contains | meets | met_by | p proge 
overlaps | overlapped-by Proges: 3 p eaprs: 
aRel ::= zape Ss | pers prog pdcl end declaration 
P identifier 
ty ::= types: 
longt type identifier catdcl cat decls: 
reference reference catalog catbind generative 
refinement n @e refine, n € N format fid:ty = format 
aggregate e(,e)@ e aggregation d where e 
select x:ty where e<e) inclusion empty 
|ty| duration catdcl;catdcl sequential 
ty & ty<& ty) conjunction catbind :: PO cat binds: 
ty | ty<| ty) disjunction cd{:s)= cate 
ty \ ty except cate ::= cat exprs: 
ty #< ty coarser-restrict cat catdcl end generative 
ty #> ty finer-restrict ed identifier 
dai = decks: cate.cd quor a 
type t = ty type catalog cd catalog 
group t = wspec group 
dcl;dcl sequential 
wspec ::= with specs: 


with ty (type t 
where e;e for t1=t2) 


